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Beschreibung 

Verfahren zur Realisierung von Anf orderungen von Telekommuni- 
kationsteilnehmern 

Die vorliegende Erfindung betrifft ein Verfahren zur Reali- 
sierung von Anf orderungen von Telekommunikationsteilnehmern 
an von einem Kommunikationsnetz bereitstellbare Dienste. Im 
Dialog mit Telekommunikationsteilnehmern, d.h. mit unmittel- 
baren Nutzern, beispielsweise den sogenannten Subscribern, 
mit den Diensteanbietern (Provider) oder mit den Netzwerkope- 
ratoren, kommen immer wieder Anderungswiinsche bezuglich der 
vom Kommunikationsnetz bereitstellbaren Dienste auf . Bei 
letzteren handelt es sich dabei vorrangig um sogenannte IN- 
Dienste, d.h. um Dienste, die liber den reinen Ubermit t lungs - 
dienst und dessen erganzende Dienstmerkmale hinausgehen. Im 
Allgemeinen werden diese durch das Intelligente Netz (IN) be- 
reitstellbaren Dienste durch das Zusammenwirken mehrerer 
technisch in sich abgeschlossenen Funktionseinheiten reali- 
siert. Diese technischen Funktionseinheiten, auch T-Features 
genannt, werden dabei entsprechend in das Intelligente Netz 
integriert . 

Bei jedem neu aufkommenden Anderungswunsch seitens der Tele- 
kommunikationsteilnehmer bzw. -kunden war es bislang notig, 
diesen im Einzelnen zu analysieren, um ihn dann individuell 
durch eine oder mehrere entsprechend miteinander zu koppelnde 
technische Funktionseinheiten (T-Features) zu realisieren. 
Diese Vorgehensweise erfordert einen hohen Zeitaufwand, da 
fur jeden Anderungswunsch bzw. fur jede neue Anforderung an 
einen vom Kommunikationsnetz bereitstellbaren Dienst aus ei- 
ner Reihe von technischen Funktionseinheiten immer wieder neu 
diejenigen Funktionseinheiten (T-Features) herausgesucht wer- 
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den miissen, die zur Realisierung in Frage kommen, und diese 
T- Features dann wiederum entsprechend miteinander gekoppelt 
werden mussen. 

Aufgrund des generell schnelllebigen Telekommunikationsmark- 
tes und der immer grofier werdenden Anzahl von Anderungswiin- 
schen beziiglich der verschiedensten vom Kommunikationsnetz 
bereitstellbaren IN-Dienste, ist es wichtig, diesen Wiinschen 
aufgrund der gleichzeitig immer groSer werdenden Konkurrenz 
auf dem Telekommunikationsmarkt , schnellst moglich gerecht zu 
werden . 

Eine Aufgabe der vorliegenden Erfindung war es demnach, ein 
einf aches und schnelles Verfahren zur Realisierung bzw. Um- 
setzung von Anf orderungen von Telekommunikationsteilnehmern 
an von einem Kommunikationsnetz bereitstellbare Dienste be- 
reitzustellen. 

Gelost wird diese Aufgabe durch ein Verfahren gemaS Anspruch 
1 und mittels der Nutzung eines Systems gemaS Anspruch 4 . 
Vorteilhafte Ausf uhrungsf ormen sind in den entsprechenden Un- 
teranspriichen angef iihrt . 

GemaS Anspruch 1 wird erf indungsgemaS ein Verfahren zur ein- 
fachen Realisierung von Anf orderungen von Telekommunikations- 
teilnehmern an von einem Kommunikationsnetz bereitstellbare 
Dienste bereitgestellt , wobei das Verfahren mindestens die 
folgenden Schritte aufweist: 

a. Abstrahieren und Klassif izieren der Anf orderungen 
in eine entsprechende Anzahl von Klassen (R- 
Features) , 

b. Unterteilen der einzelnen Klassen (R-Features) in 
ein Oder mehrere Unterklassen (usages) , 
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c. Eindeutiges Zuordnen einer Unterklasse zu einer 

Oder mehreren entsprechend miteinander zu koppeln- 
den technischen Funktionseinheiten (T-Features) . 

5 Wahrend man bislang immer wieder von Neuem mit einem speziel- 
len Anderungswunsch bzw. einer speziellen Anforderung seitens 
der Telekommunikationsteilnehmer , d.h. der Subscriber, der 
Provider oder der Netzwerkoperatoren konfrontiert war und 
diese Anforderung (Requirement) dann individuell hinsichtlich 
10 seiner moglichen technischen Realisierbarkeit analysieren 

musste, ist es nun moglich jede spezielle Anforderung in ei- 
ner Klasse, bzw. einem R-Feature (Requirement -Feature) wie- 
derzufinden. Erf indungsgemaS werden alle bisher auf getretenen 
Anderungswiinsche zunachst abstrahiert, d.h, losgelost von ei- 
15 nem bestimmten Dienst gesehen. Sodann lassen sie sich 

dienstunabhangig klassif izieren bzw. katagolisieren. Es erge- 
ben sich dabei erf indungsgemaS eine bestimmte, abzahlbare An- 
zahl von Klassen, sogenannte R-Features (Requirements- 
Features) . Diese R-Features bilden dabei oft eine Art „Ober- 
20 begriff und lassen sich meist wiederum etwas dif f erenzieren 
bzw. spezif izieren, wobei sich jeweils eine bestimmte Anzahl 
von Unterklassen, sogenannte Usages, herauskristallisieren . 
' Man erhalt so einen Katalog von Anf orderungen (R-Features) , 

ahnlich einem Baukasten, bestehend aus verschiedenen Lego- 
25 steinen, mit dessen Hilfe man im wesentlichen alle neu auf- 
kommenden Anderungswiinsche seitens der Telekommunikations- 
teilnehmer aus R-Features „zusammenbauen" bzw. zusammensetzen 
kann. Ein eventuell verbleibender kleiner, nicht durch R- 
Features abdeckbarer Teil der Anderungswiinsche muss individu- 
3 0 ell realisiert werden. Je nach Bedeutung dieses eventuell 

verbleibenden Teils ist abzuwagen, ob es sinnvoll erscheint, 
diesen als neues R-Feature in die erf indungsgemaSe Klassif i- 
zierung mit aufzunehmen. 
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In Phase 1 werden zunachst die Anf orderungen (Requirements) 
der Subscriber, der Provider und der Netzwerkoperatoren an 
verschiedene Dienste und deren Verwaltung (management) gesam- 
melt. Im Anschluss daran sichtet man den Bestand an definier- 
ten R- Features aus der erf indungsgemaS vorgenommenen Klassi- 
fizierung nach Schritt a. des erf indungsgemaSen Verfahrens 
und ordnet die gestellten Anf orderungen entsprechend ein. Man 
erhalt so eine einfache Zuordnung der gestellten Anforderun- 
gen zu bestimmten realisierbaren, vorzugsweise diensteunab- 
hangigen R-Features. Der Vorteil bei dieser Vorgehensweise 
liegt darin, dass man es nach Phase 1 nicht mehr mit einzel- 
nen individuellen Anf orderungen zu tun hat, sondern mit fur 
mehrere Dienste vereinheitlichbaren Anf orderungen . Dadurch 
wird auch die Realisierung der entsprechenden Anf orderungen 
im GroSen und Ganzen diensteunabhangig und universeller ein- 
setzbar . 

In Phase 2 werden die Anf orderungen beziiglich ihrer „Sinnhaf- 
tigkeit" gepruft, d.h. es werden die technischen bzw. durch- 
fiihrbaren, die okonomischen (Kosten, Performance) und die 
funktionalen Aspekte beleuchtet. Zur Durchfiihrung dieser Pha- 
se kommen Marktsimulationen und Kunden-Workshops in Frage . Es 
wird die Wirkung auf sich gegenseitig beeinf lussende Systeme 
und Organisationen analysiert. Man erhalt so letztlich eine 
genaue Vorstellung von der wirklich gewiinschten und zu reali- 
sierenden bzw. umzusetzenden Anforderung. Gleichzeitig ergibt 
sich in einem sehr friihen Entwicklungsstadium eine Vorabein- 
schatzung der entstehenden Entwicklungskosten sowie der Ein- 
fuhrungs- und dann sich ergebenden laufenden Kosten bei Rea- 
lisierung bzw. Umsetzung der Anforderung in entsprechenden 
IN-Diensten des Intelligenten Netzes. Vorzugsweise soil in 
dieser Phase die Anforderung bzw. die Dienstidee zusammen mit 
dem jeweiligen Telekommunikationsteilnehmer unmittelbar vor 
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Ort besprochen, spezifiziert und verifiziert warden. Jeder 
Unterklasse bzw, jedem usage ist erf indungsgemaS ein wohl de- 
finierteS/ bereits getestetes und realisiertes Modell zuor- 
denbar. Zur Simulation eines Dienstes, der sich nach vorge- 
nommener Analyse aus einer bestimmten Anzahl von usages zu- 
sammensetzen lasst, fiigt man nun die entsprechenden, den ein- 
zelnen usages zuordenbaren Modelle in einem Simulat ionstool 
zu einem Gesamtmodell zusammen und kann damit iiberprufen, ob 
die Anforderung bzw. die Dienstidee erfasst wurde . Dadurch 
kommt es sehr friih, d.h. noch vor der eigentlichen Umsetzung 
der Anforderung durch technische Funktionseinheiten, zur Auf- 
klarung von eventuellen Missverstandnissen. Gleichzeitig las- 
sen sich durch solche Simulationen eventuell noch andere Vor- 
ziige beziiglich eines Dienstes mit einbauen. 

In Phase 3 erfolgt der eigentliche Ubergang von den R- 
Features zu den T-Features. Dabei wird genau analysiert, was 
eigentlich durch die gestellte Anforderung letztlich funktio- 
nal umgesetzt werden muss. Es wird ein direkter Zusammenhang 
hergestellt zwischen Anforderung (R-Feature) und funktionaler 
Umsetzung (T-Feature) . Das oder die miteinander zu koppelnden 
T-Features miissen dabei in ihrer Funktion der gestellten An- 
forderung genuge tun. Gleichzeitig ergibt sich durch diese 
Zuordnung eine genauere Spezif izierung hinsichtlich der Ver- 
waltung eines der gestellten Anforderung gerecht werdenden 
Dienstes . Das Zusammenwirken mit externen Systemen lasst sich 
analysieren und beurteilen. 

Erf indungsgemaS ergibt sich durch die Klassif izierung der R- 
Features eine klare, exakte und unzweideutige Abb il dungs vor - 
schrift von der Seite der R-Features auf die Seite der T- 
Features. Diese Abbildungsvorschrif t erleichtert und be- 
schleunigt den gesamten Entwicklungsprozess . 
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in Phase 4 wird die richtige Zuordnung durch Tests anhand von 
Modellen verifiziert, d.h. es wird gepruft. ob die funktio- 
nelle Spezif izierung nach Phase 3 auch wirklich die gestell- 
ten Anforderungen an den oder die entsprechenden Dienste er- 
fvillt Bei der Verif ikation kann gleichzeitig eine Abschat- 
zung bezuglich der Leistungsfahigkeit bzw. der Performance 
der funktionellen Realisierung getroffen werden. Eine derar- 
tige verifikation findet vorzugsweise mittels Simulationen 
statt. ErfindungsgemaS gibt es zu jedem T-Feature ein realx- 
siertes, wohl definiertes Model 1 . Ahnlich wie bei der Sxmula- 
tion auf Ebene der R-Features, wie dies unter Phase 2 erlau- 
tert ist, werden auch hier zur Verifikation der Funktionalx- 
tat der entsprechend gekoppelten T-Features, die einzelnen 
Modelle der in Frage kommenden T-Features entsprechend mxt- 
einander zu einem Gesamtmodell gekoppelt, um so den gewunsch- 
ten Dienst auf Ebene der T-Features simulieren und somit 
uberprufen zu k6nnen. 

Die Phasen 5, 6 und 7 beinhalten letztlich die eigentliche 
tatsachliche Realisierung der entsprechenden R-Features. In 
Phase 6 werden Testl^ufe, vorzugsweise in der entsprechenden 
Netzwerkumgebung durchgef uhrt . Sowohl Dienste- wie auch Ver- 
waltungsanwendungen werden kontrolliert . Festgestellte Fehler 
Oder Mangel werden korrigiert . Phase 7 umfasst sowohl dxe 
Dienste- wie auch die Verwaltungsinstandhaltung . 



2001 -P 03382 D: 



Patentanspriiche 

1. verfahren zur einfachen Realisierung von Anf orderungen von 
Telekommunikationsteilnehmern an von einem Kommunikationsnetz 
bereitstellbare Dienste, wobei das Verfahren mindestens die 
folgenden Schritte aufweist: 

a) Abstrahieren und Klassif izieren der Anf orderungen in eine 
entsprechende Anzahl von Klassen (R-Features) , 

b) Unterteilen der einzelnen Klassen (R-Features) in ein oder 
mehrere Unterklassen (usages) , 

c) Eindeutiges Zuordnen einer Unterklasse zu einer oder meh- 
reren entsprechend miteinander zu koppelnden technischen 
Funktionseinheiten (T-Features) . 

2. Verfahren nach Anspruch 1, 
dadurch gekennzeichnet, 

dass das verfahren mindestens noch den folgenden weiteren 
Schritt aufweist: 

d) Durchfuhren mindestens. eines Testlaufes der entsprechend 
nach c. zugeordneten technischen Funktionseinheiten. 

3. Verfahren nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, 

dass die schritte a. bis c. jeweils durch ein oder mehrere 

Simulationslaufe verifiziert warden konnen. 

4. system zur einfachen Realisierung von Anf orderungen von 
Telekommunikationsteilnehmern an von einem Kommunikationsnetz 
bereitstellbare Dienste, wobei das System mindestens die fol- 
genden Systemeinheiten aufweist: 

a) einen ersten Katalog von Klassen (R-Features) , wobei jede 
Ahforderung genau einer Klasse zuordenbar ist. 
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b) einen zweiten Katalog von technischen Funktionseinheiten 
(T- Features) , wobei jeder Klasse aus a. jewei*ls genau ein 
Oder mehrere bestimmte technische Funktionseinheiten zuor- 
denbar sind. 

5 

5. System nach Anspruch 4, 

dadurch gekennzei c.h net, 

dass die Klassen aus a. jeweils in ein oder mehrere Unter- 
klassen (Usages) unterteilt sind und jeder dieser Unterklas- 
10 sen jeweils genau ein oder mehrere bestimmte technische Funk- 
tionseinheiten (T-Features) zuordenbar sind. 

6. System nach Anspruch 4 oder 5, 
dadurch gekennzeichnet, 

15 dass jeder Klasse (R-Feature) mindestens ein realisiertes , 
definiertes Mbdell zugeordnet ist. 

7. System nach einem der Anspriiche 4 bis 6, 
dadurch gekennzeichnet, 

20 dass jeder technischen Funktionseinheit (T-Feature) ein rea- 
lisiertes, definiertes Modell zugeordnet ist. 
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